This PR basically reverts #32374, which added detection of parameterized Contains inside aggregate function invocations, to avoid translating that to an OPENJSON subquery (as usual) but to instead fall back to the traditional IN+constants translation.

This PR now adds general support for IN+subquery - OPENJSON or otherwise - by lifting it out to OUTER APPLY, so we can remove the special casing and use OPENJSON.

Note that this creates more complicated SQL (see below).

Note the parameterized Contains change, as mentioned above. We now do IN+subquery with OPENJSON, just like everywhere else; the new postprocessing step then lifts that subquery up to an OUTER APPLY.

This makes the SQL more complex; I don't think there's a significant perf aspect here since I'm assuming no indexes would be used anyway for these cases. In any case, the OPENJSON vs. constants question is its own separate discussion, so I think it's the right thing to remove the special-casing here for SQL Server.

/cc @cincuranet

@ranma42 you may be slightly interested in this (I know you have no context whatsoever)... This specific test shows us lifting an EXISTS subquery out when it's nested inside an aggregate function call (not supported by SQL Server), and integrating it as an OUTER APPLY, at which point it can be referenced from inside the aggregate function call.

Specifically with EXISTS, it's funny/painful to see how we need to translate the boolean (search condition) to bit for projection out of the OUTER APPLY, and then to translate it back to bool via CASE/WHEN in the projection... So much trouble and ceremony due to the lack of a proper bool type.

would something like [s].[value] * [s0].[OrderID] make sense for this?

EDIT: already handled by #34262 (comment)

Note the CROSS JOIN instead of CROSS APPLY here, since the subquery is uncorrelated.

would it be possible to have

    OUTER APPLY (
        SELECT 5 + MAX([o0].[ProductID]) AS [value]
        FROM [Order Details] AS [o0]
        WHERE [o].[OrderID] = [o0].[OrderID]
    ) AS [s]

here?

I don't expect this to perform better; it is mainly for readability, so just ignore this if it is not trivial 😇

Yeah, that's a good suggestion but it seems orthogonal to this PR (i.e. the original SQL on the left had the same thing). Maybe open an issue to track that potential optimization?

Opened #34314 to track this

you can use custom asserter to verify results with some error margin:

        => AssertAverage(
            async,
            ss => ss.Set<Customer>().OrderBy(c => c.CustomerID).Take(3),
            selector: c => (decimal)c.Orders.Average(o => 5 + o.OrderDetails.Average(od => od.ProductID)),
            asserter: (e, a) => Assert.Equal(e, a, precision: 3));